Systems and methods of blockchain platform for intermediaries and passwordless login

ABSTRACT

The systems and methods on a blockchain platform for one or more intermediaries for services including proxy re-encryption, independent audit, multiple-signatures based smart wallet associated with a smart contract and split-key authentication to achieve secure passwordless login. Proxy re-encryption by receiving a ciphertext from a first user with condition parameters that has been encrypted with a dynamically selected encryption algorithm. Audit service receiving an encrypted file from a user for storage on the blockchain platform; enforcing the security policy parameters for all access requests to the file on the blockchain platform; and optionally providing audit report of the encrypted file storage and access. A smart wallet with a group key using multiple signatures based on receipt of a threshold number of signatures. Split-key authentication by splitting the private key into two or more parts; and assigning the split private key part to two or more client devices.

If an Application Data Sheet (ADS) has been filed on the filing date ofthis application, it is incorporated by reference herein. Anyapplications claimed on the ADS for priority under 35 U.S.C. §§ 119,120, 121, or 365(c), and any and all parent, grandparent,great-grandparent, etc. applications of such applications, are alsoincorporated by reference, including any priority claims made in thoseapplications and any material incorporated by reference, to the extentsuch subject matter is not inconsistent herewith.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is related to and/or claims the benefit of theearliest available effective filing date(s) from the following listedapplication(s) (the “Priority Applications”), if any, listed below(e.g., claims earliest available priority dates for other thanprovisional patent applications or claims benefits under 35 USC § 119(e)for provisional patent applications, for any and all parent,grandparent, great-grandparent, etc. applications of the PriorityApplication(s)). In addition, the present application is related to the“Related Applications,” if any, listed below.

RELATED APPLICATIONS

This application is related to co-pending patent application Ser. No.16/247,994 filed on Jan. 15, 2019.

FIELD OF THE INVENTION

The present invention is in the technical field of cloud computing. Moreparticularly, the present invention is in the technical field ofblockchain platform. More particularly, the present invention is in thetechnical field of proxy re-encryption, multiple signatures andpasswordless login or authentication using split keys on a blockchainplatform.

BACKGROUND

Internet is a global computer network providing a variety of informationand communication facilities, consisting of interconnected networksusing standardized communication protocols. Internet is not owned by asingle entity and it operates without a central governing body. The sameprinciples of distributed governance were applied to digital currenciesby providing ability to perform digital transactions that existedwithout support from any underlying institution. The digital ledger thatrecords the transactions in a chain using a mathematical hierarchy iscalled a blockchain. The following paragraphs describe differentscenarios that exist today in the context of cloud computing andblockchain environments and systems.

As a background, a proxy server acts as a gateway or an intermediaryserver separating end users from the websites they browse. Using a proxyserver helps with controlling internet usage of employees and children,bandwidth savings, improved speeds, privacy benefits, improved securityand access to blocked resources by pretending to be at anothergeographical location. Proxy Re-Encryption is a specializedcryptographic primitive that facilitates a user to share his encryptedfile with another user without decrypting the file using a specializedkey called Re-Encryption Key (ReKey). Proxy controls which ciphertext ofthe user needs to be translated or re-encrypted. There are no mechanismsknown in the industry that allow flexible user control to proxyreencryption.

The current model of cloud storage is operated through centralizedauthorities, which makes such a system susceptible to single pointfailures and permanent loss of data. Blockchain technology, initiallydesigned as a financial ledger has attracted the attention ofresearchers in a wide range of applications requiring accountablecomputing and auditability. Blockchain enabled distributed peer-to-peercloud storage solutions are steadily replacing its centralizedcounterpart. A blockchain provides multiple parties to agree upontransactions and contracts in an immutable and auditable way.Decentralized applications such as dApp providers make use of thiscapability to provide services that are transacted in a publiclyverifiable manner. When the service provided by the dApp is not directlyfrom the dApp owner itself but from other third parties, it brings upadditional challenges. How would the end user using the dApp trust thatthe unknown third party service provides used by the dApp are trustworthy? The current approaches in the industry use a combination ofunencrypted to cumbersome ways.

While there are policies in the industry that provide end-to-end userflexibility in securing content from authoring to distribution, none ofthem offer flexibility in a blockchain setup where there is no singleentity on the cloud controlling access. While most systems offersecuring content, they may fall short of providing an independentlyverifiable audit capability. In a world of increasing cyber crime anddigital fraud, when something goes wrong, it requires a lot of time andeffort to do digital forensic investigation. Blockchains can help reducethis burden by ensuring tamper-proof auditability is part of theenterprise workflows.

While there are means to enable shared smart contracts, a wallet istypically assigned to a single person or entity. For an entity hosting asmart wallet, there may be more than one person who has the accessrights to make decisions of spending or buying on that smart wallet. Insuch a situation, the entity smart wallet authentication system isvulnerable if passwords are shared by two or more people. Such avulnerability could also exist for a smart wallet associated with ahousehold that has two or more members with access privileges.

Most of the existing and prevalent authentication methods rely onpassword-based authentication. Enterprises already use a single-sign onto make it easy for their employees to login to their various internalapplications that each require login. Some require changing the passwordevery few weeks or months. Some even prevent reusing the previous 10passwords, making it extremely painful to employees. While this improvesthe security, it imposes unnecessary burden on the employees. There isno simple, seamless and effortless method to provide access withoutcompromising on the level of security provided. With cybersecurity andprivacy laws, enterprises have a higher need to provide a higher levelsecurity.

SUMMARY OF THE INVENTION

The present invention is systems and methods on a blockchain platformfor one or more intermediaries comprising: receiving a ciphertext from afirst user with condition parameters that has been encrypted with adynamically selected encryption algorithm; receiving a re-encryption keyfor a second user from the first user; identifying whether theciphertext is valid; re-encrypting the ciphertext; outputting there-encrypted ciphertext only if the ciphertext is valid; and achievingsecurity against chosen ciphertext attack and distributeddenial-of-service attack; sending the re-encrypted ciphertext to thesecond user for decryption.

The system and method for intermediaries, wherein the intermediary doesnot have the ability to decrypt the received ciphertext.

The system and method for intermediaries, further comprising: skippingoutputting the re-encrypted ciphertext based on one or more conditionparameters.

The system and method for intermediaries, further comprising: sendingthe re-encrypted ciphertext to a second intermediary for second hopre-encryption.

A system and method of a blockchain platform for an intermediary,comprising: receiving an encrypted file from a user for storage on theblockchain platform; mapping the user to be the owner of the encryptedfile; receiving one or more security policy parameters for the encryptedfile from the owner; enforcing the security policy parameters for allaccess requests to the file on the blockchain platform; and optionallyproviding audit report of the encrypted file storage and access.

The system and method for intermediaries, wherein the owner isestablished using past read or write transactions performed directly onthe blockchain platform.

The system and method for intermediaries, further comprising: dividingthe encrypted file into two or more parts before sending for storage onthe blockchain platform.

A system and method of a blockchain platform for a smart wallet,comprising: assigning a total number of two or more public-private keypairs for users associated with the smart wallet; allocating a thresholdnumber for approval on transaction on the smart wallet wherein thethreshold number is less than or equal to the total number; creating agroup key from the total number of public-private keys and the thresholdnumber for approvals; using the group key to register the smart walleton the blockchain; receiving for a transaction a shared signature basedon the group key from two or more users; validating and finalizing thetransaction when the received signatures are more than the thresholdnumber.

The system and method of the smart wallet, wherein: the smart walletwith the group key supports all the functions of a single user wallet.

A system and method of blockchain platform for authenticating clients,comprising of: creating a public and private key at a client device;splitting the private key into two or more parts; assigning the splitprivate key part to two or more client devices; signing to authenticatea challenge using a partial key part at one of the client devices;sending the challenge to the remaining client devices who sequentiallysign using short range wireless network connection; responding back tothe challenge to login without a password.

BRIEF DESCRIPTION OF THE DRAWINGS

The embodiments of this invention are illustrated by way of example andnot limitation in the figures of the accompanying drawings, in whichlike references indicate similar elements and in which:

FIG. 1 shows a diagram illustrating an example of a system and method ona blockchain platform with intermediaries, clients and serviceproviders.

FIG. 2 shows Table 1 and Table 2. Table 1 discloses PerformanceEvaluation of the CPA secure El-Gamal Encryption Scheme and disclosedSelf-Encryption Scheme. Table 2 discloses Performance Evaluation of theefficient pairing-free unidirectional PRE scheme due to Chow et al., anddisclosed Scheme.

FIG. 3 is an exploded view of an intermediary computing systemillustrating different modules and functions, according to oneembodiment.

FIG. 4 discloses an encrypted file access with independent audit serviceprovider work flow illustrating different modules and functions,according to one embodiment.

FIG. 5 discloses messaging work flow to access an encrypted file andaudit reporting on a blockchain platform with server-side integration,according to one embodiment.

FIG. 6 discloses messaging work flow to access an encrypted file andaudit reporting on a blockchain platform with server and client-sideintegration, according to one embodiment.

FIG. 7 is a schematic diagram of exemplary computing devices that can beused to implement the methods and systems disclosed herein, according toone embodiment.

FIG. 8 discloses messaging flow for multiple signatures smart contractimplementation, according to one embodiment.

FIG. 9 discloses messaging flow for multiple signatures smart walletimplementation, according to one embodiment.

FIG. 10 discloses messaging flow for password less login usingsplit-keys, according to one embodiment.

FIG. 11 is a flow chart showing different method steps in implementingpassword less login using split-keys, according to one embodiment.

DETAILED DESCRIPTION OF THE INVENTION

The systems and methods on a blockchain platform for intermediaries andpasswordless login allow for intermediary proxy re-encryption,independent audits, secure multiple persons controlled smart contract orsmart wallet, and split-keys short-range wireless device-based andpasswordless client authentication. One or more entities (or serviceproviders) that help or manage the self-regulation on the blockchainplatform are miners. A client is an end-user with two or more computingdevices who initiates the requests and wants to commit transactions onthe blockchain platform. An intermediary may be a blobber or a sharderwho uses a computing device that processes the applications on theblockchain platform.

Different embodiments described herein include components or structuresto perform the described functionality. A “component” or a “module” asused in this invention disclosure, includes a dedicated or sharedprocessor and, typically, firmware or software modules executed by theprocessor. Depending upon implementation-specific or otherconsiderations, a module can be centralized or its functionalitydistributed. A component or a module can include special purposehardware, firmware, or software embodied in a computer-readable mediumfor execution by the processor.

In one embodiment, FIG. 1 depicts a diagram 100 illustrating an exampleon a blockchain platform with intermediaries. In the example of FIG. 1,the environment includes a first consumer or client system 110-1 throughan nth client system 110-n wherein each client owns two or more devices1, 2, 3, . . . n, network 140, intermediary system 120-1 through an nthintermediary system 120-n and a service provider 130-1 through an nthsystem 130-n. In an implementation, the client system 110 includescomponents related to requesting services from the blockchain platform.In one implementation, the client system 110 requests and uses a storageapplication for storage, read or write. The client may use a multiplesignatures or group-based smart-contract or smart-wallet on theblockchain platform. The client may use passwordless authenticationusing split keys that are associated with two or more client devices.The client may request audit reporting for any of its transactionsincluding storage read/write requests or adding/deleting of tokens froma smart contract or smart wallet.

The intermediary provides enforcement to parameters set with flexibilityby a client including security policies on an encrypted file owned by aclient. The intermediaries operate securely on the blockchain platform.The clients can delegate reencryption and use intermediaries as proxies.The intermediary can be providing proxy services, audit reportingserver, enforcing multiple signatures on a smart contract or a smartwallet, provider of server-side passwordless authentication.

The service provides provide the underlying blockchain platform basicoperations functionality. The blockchain platform may operate on atoken-based transaction system. For example, in one embodiment, theservice providers manage tokens when using a resource on the blockchainor when providing service.

Network 140 can be different wireless and wired networks available toconnect different computer devices including client and server systems.In an implementation, network 140 is publicly accessible on theinternet. In an implementation, network 140 is inside a secure corporatewide area network. In an implementation, network 140 allows connectivityof different systems and devices using a computer-readable medium. In animplementation, the blockchain platform allows users on the clientsystem, the blobber, the sharder or the miner to have customizedapplications and operational framework.

The messaging and notification between different components can beimplemented using application programming interface (API) calls,extensible markup language (“XML”) interfaces between differentinterfaces, Java/C++ object oriented programming or simple web-basedtools. Different components may also implement authentication andencryption to keep the data and the requests secure.

I. Sharing of Encrypted Files on Blockchain Using Pre

The recent explosion of data volumes and demand for computing resourceshave prompted individuals and organizations to outsource their storageand computation needs to online data centers, such as cloud storage.While data security is enforced by standard public-key encryptionmechanisms in the cloud, secure data sharing is enabled by efficientcryptographic primitives such as proxy re-encryption (PRE). PRE enablesre-encryption of ciphertexts from one public key into another via asemi-trusted third party termed proxy, who does not learn anyinformation about the underlying plaintext. A user can delegate accessto his files by constructing a special key, termed as re-encryption key,using which the proxy performs the ciphertext transformation towards alegitimate delegatee. PRE systems can be classified into unidirectionaland bidirectional schemes based on the direction of delegation. They canalso be classified into single-hop and multi-hop schemes based on thenumber of re-encryptions permitted. In this work, we focus onunidirectional and single-hop PRE schemes.

Using dApp called 0Box, a storage dApp allows any user to upload andshare their files to their friends and families similar to many otherpopular storage services. However, most existing services trust theservice provider and upload the content without any encryption. But 0boxstrives to provide zero-knowledge storage such that the third-partystorage providers will not know the uploaded content. This is achievedusing an efficient CCA-secure proxy re-encryption scheme, outlined inthis paper. When a user shares the encrypted content with a trustedparty, he provides the reencryption keys using the public key of thetrusted party so that only that party is able to decrypt the content. Byfacilitating the associated transactions on the blockchain, this schemeprovides an end-to-end transparency and security for end users toprocure storage services at highly competitive prices without worryingabout the reputation of the storage providers. We first propose a novelself-encryption (SE) scheme, which is much more efficient than thestandard CPA secure El-Gamal encryption scheme. This work is furtherextended to design a CCA-secure proxy re-encryption scheme (SE-PRE) thatadds re-encryption functionality to self-encryption. Our PRE design ismuch more efficient than the schemes known in the industry.

We give the definitions of various assumptions adopted for proving thesecurity of the proposed schemes, the general and security model of SEand SE-PRE schemes. (1) Definition 1. Discrete Logarithm Problem (DLP):The discrete logarithm problem in a cyclic group G of order q is, given(q; P; Y) such that q is a large prime, P; YϵG, find aϵZ*_(q) such thatY=aP. (2) Definition 2. Computation Diffie Hellman Problem (CDH): TheComputation Diffie Hellman Problem in a cyclic group G of order q is,given (q; P; aP; bP) such that q is a large prime, P; aP; bPϵG, find Qsuch that Q=abP, where aϵZ^(*) _(q).

The self encryption (SE) is a novel primitive that allows a user tostore their files securely with minimal computation overhead. Thisprimitive is different from the traditional public key encryptionapproach as encryption can be done only by the owner of the file whopossess the private key related to the public key which is used forencrypting the file. It has the following algorithms: (1) Setup, (2)KeyGen, (3) Self-Encrypt, and (4) Self-Decrypt. Setup(k) algorithm isrun by the trusted entity. On input of a security parameter k, the Setupalgorithm will output the system parameters Params. KeyGen(Ui, Params)algorithm is run by the user Ui. This is used to generate a public andprivate key pair (PK_(i); SK_(i)) for the user Ui. Self-Encrypt(m,t_(w), SK_(i), PK_(i), Params) is an encryption algorithm is run only bythe user Ui. This algorithm requires the knowledge of the private keySK_(i) corresponding to the public key PK_(i) of user Ui. This takes asinput the message m, the tag t_(w), the private key SK_(i) and publickey PK_(i) of user Ui. It will output a ciphertext C which is theencryption of message m under the public key PK_(i) and tag t_(w). Thisapproach different from the traditional public key encryption where theencrypt algorithm can be run by any user. Self-Decrypt(C, SK_(i),PK_(i), Params): The decryption algorithm is run by the user U. On inputof the ciphertext C, the private key SK_(i) and the public key PK_(i) ofuser U_(i), this will output the message m if C is a valid selfencryption of m under PK_(i), SK_(i) and t_(w). Otherwise, it returns ⊥.In one embodiment, the generic model of Self Encryption algorithmsconsists of the algorithms described in this paragraph.

The SE-PRE is a proxy re-encryption primitive that uses a selfencryption scheme as the base algorithm and provides a mechanism todelegate the self-encrypted ciphertext. The SE-PRE scheme consists ofthe following algorithms: 1. Setup(k):The setup algorithm takes as inputa security parameter k. This will output the system parameters Params.This algorithm is run by a trusted party. 2. KeyGen(Ui, Params): The keygeneration algorithm generates a public and private key pair (PK_(i);SK_(i)) of user Ui. This algorithm is run by a user Ui. 3.ReKeyGen(SK_(i); PK_(i); PK_(j); c_(w); Params): The re-encryption keygeneration algorithm takes as input a private key SK_(i) of delegatorU_(i), public key PK_(i) of delegator U_(i), public key PK_(j) ofdelegatee U_(j) and condition c_(w) under which proxy can re-encrypt. Itoutputs a re-encryption key RK_(i->j). This is executed by the user U.4. Self-Encrypt(m, t_(w), SK_(i), PK_(i), Params): The self encryptionalgorithm takes as input the message m, the tag t_(w), the private keySK_(i) of user U_(i) and public key PK_(i) of the user U. It outputs aciphertext C which is the encryption of message m under the public keyPK_(i), private key SK_(i) and tag t_(w). This algorithm is executed bythe user U_(i). 5. Re-Encrypt(C; PK_(i); PK_(j); c_(w); RK_(i->j);Params): The re-encryption algorithm takes as input a self-encryptedciphertext C, the delegator's public key PK_(i), the delegatee's publickey PK_(j), the condition c_(w) and a re-encryption key RK_(i->j)corresponding to c_(w). It outputs a ciphertext D which is theencryption of same m under public key PK_(j) of user U_(j). This is runby a proxy who is provided with the re-encryption key RK_(i->j). 6.Self-Decrypt(C, SK_(i), PK_(i), Params): The self decryption algorithmis run by the user U. This will take as input the ciphertext C, theprivate key SK_(i) of user U_(i) and public key PK_(i) of user U. Itwill output the message m if C is a valid encryption of m under PK_(i)and Sk_(i) of user U_(i) and tag t_(w). If C is not valid, thisalgorithm returns ⊥. 7. Re-Decrypt(D, SK_(j), Params): The re-decryptionalgorithm takes as input a re-encrypted ciphertext D and a private keySK_(j) of user U_(j). It outputs a message mϵM, if D is a validre-encrypted ciphertext of message m or the error symbol ⊥ if D isinvalid. This algorithm is run by the user U_(j). In one embodiment, thegeneric model of proxy re-encryption with self-encryption (SE-PRE)includes algorithms described in this paragraph.

The security model gives details about the restrictions and oracleaccesses given to the adversary. It is modelled as a game between achallenger C and an adversary A. The security of Self-Encryption (SE)scheme against chosen ciphertext attacks (IND-SE-CCA) is demonstrated asa game between an adversary A and a challenger C. The game is asfollows: (1) Setup: C takes a security parameter k and runs the Setup(k)algorithm to generate the system parameters Params. It provides Paramsto A. C then runs KeyGen(U; Params) to generate a private and public keypair SK; PK of user U and provides PK to A. SK is kept by A. (2)Phase-1: A can adaptively issues queries to the following oraclesprovided by C: Self-Encrypt(m; t_(w)) Oracle: C runs the Self-Encrypt(m,t_(w), SK, PK, Params) algorithm to generate the ciphertext C andreturns it to A. Self-Decrypt(C, PK) Oracle: C runs the Self-Decrypt(C,SK, PK, Params) and returns the output to A. (3) Challenge: Aftergetting sufficient training, A submits two messages m0 and m1 from M ofequal length and a tag t_(w)* to C. C picks a random bit δϵ{0; 1} andoutputs the ciphertext C*=Self-Encrypt(m_(δ); t_(w)*, SK; PK). (4)Phase-2: On receiving the challenge C*, A is allowed to access thevarious oracles provided in Phase-1 with the restrictions given below:(i). Self-Decrypt(C*) query is not allowed. (ii) Self-Encrypt(m_(δ);t_(w)*) query is not allowed. (5) Guess: After getting sufficienttraining, A will output its guess. A wins the game if δ=δ′. In oneembodiment, the security model for self-encryption includes algorithmsdescribed in this paragraph.

Security model for the SE-PRE scheme is described below. The modelinvolves the security of original ciphertext as well as transformedciphertext. The ciphertext that can be re-encrypted is called theoriginal ciphertext and the output of the re-encryption is called thetransformed ciphertext. Security of Original Ciphertext: The security ofProxy Re-Encryption with Self-Encryption (SE-PRE) schemes against chosenciphertext attacks (IND-SE-PRE-CCAO) for the original ciphertext ismodelled as a game between an adversary A and a challenger C. Thesecurity game is described below: (1) Setup: C takes a securityparameter k and runs the Setup(k) algorithm to generate the systemparameters Params. The Params is then given to A. (2) Phase-1: Onreceiving the system parameters, a target public key PK_(T) and tagt_(w)*, A is allowed to access Keygen, Self-Encrypt, Self-Decrypt,Rekey, Re-Encrypt, Re-Decrypt algorithms. A simulates the algorithms asoracles and A can adaptively issue queries to these oracles. The variousoracles provided by C are: (a) Corrupted KeyGen(U_(i)): C runs theKeyGen(U_(i); Params) to obtain the public and private key pair (PK_(i);SK_(i)). C returns both SK_(i) and PK_(i) to A. (b) UncorruptedKeyGen(U_(i)): C runs the KeyGen(U_(i); Params) to obtain the public andprivate key pair (PK_(i); SK_(i)) and returns PK_(i) to A. SK_(i) is notprovided to A. (c) ReKeyGen(U_(i);U_(j)): C runs the ReKeyGen(SK_(i);PK_(i); PK_(j); c_(w); Params) to obtain the re-encryption keyRK_(i)!_(j) and returns it to A. (d) Self-Encrypt(m; t_(w); PK_(i)): Cruns the Self

Encrypt(m, t_(w), SK_(i), PK_(i), Params) to obtain the ciphertext C andreturns it to A. (e) Re-Encrypt(C, PK_(i), PK_(j), c_(w)): C runs theRe-Encrypt(C; PK_(i); c_(w); RK_(i)!_(j); Params) to obtain theciphertext D and returns it to A. Here, RK_(i)!_(j) is the re-encryptionkey from PK_(i) to PK_(j) under the condition c_(w). (f) Self-Decrypt(C,PK_(i)): C runs the Self-Decrypt(C, SK_(i), PK_(i), Params) and returnsthe output to A. (g) Re-Decrypt(D, PK_(j)): C runs the Re-Decrypt(D,SK_(j), PK_(j), Params) and returns the output to A. For the ReKey,Encrypt, Re-Encrypt, Decrypt, Re-Decrypt oracle queries it is requiredthat public keys PK_(i) and PK_(j) are generated beforehand. (3)Challenge: On getting sufficient training, A will output twoequal-length plaintexts m0, m1 2 M. Here, the constraint is: PK_(T) isgenerated using Uncorrupted Keygen and Rekey(PK_(T), PK_(j), c_(w)); isnot queried in Phase-1 for c_(w)=t_(w)* C flips a random coinf0; 1 g,and sets the challenge ciphertext C*=Self-Encrypt(m, t_(w)*, SK_(T),PK_(T), Params). C then provide C* as challenge to A. (4) Phase-2: A canadaptively query as in Phase-1 with the following restrictions: 1. Acannot issue Corrupted KeyGen(U_(T)) query. 2. A cannot issueSelf-Decrypt(C*, PKT, t_(w)*) query. 3. A cannot issue Re-Encrypt(C*,PK_(T); PK_(j)) query on C* from PK_(T) to PK_(j) if PK_(j) isCorrupted. 4. A cannot issue ReKey(PK_(T), PK_(j); c_(w)) query ifc_(w)=t_(w)*. 5. A cannot issue Re-Decrypt query on D*; PK_(j) if D* isthe output of Re-Encrypt(C*,PK_(T), PK_(j), c_(w)) and c_(w)=t_(w)* (5)Guess: Finally, A outputs a guess δ′ϵ{0; 1} and wins the game if δ′=δ.

The security of transformed of Proxy Re-Encryption withSelf-Encryption(SE-PRE) scheme against chosen ciphertextattacks(IND-SE-PRE-CCAT) is modelled as a game between an adversary Aand a challenger C. This is achieved by: (1) Setup: C takes a securityparameter k and runs the Setup(k) algorithm and gives the resultingsystem parameters Params, a target public key PK_(T) and tag t_(w)* toA. (2) Phase-1: This phase is similar to the Phase-1 ofIND-SE-PRE-CCA_(O). We do not provide Re-Encrypt oracle as we areproviding all the re-encryption keys for the adversary. (3) Challenge:Once A decides Phase-1 is over, it outputs two equal-length plaintextsm₀,m₁ϵM. C flips a random coin δ ϵ{0; 1}, and sets the challengeciphertext as follows: (a) Compute C*=Self-Encrypt(m, t_(w)*, SK_(i),PK_(i), Params), (PK_(i); SK_(i) be the public, private key pair of userU_(i) and U_(i) can be honest or corrupt. (b) SetsD*=Re-Encrypt(C*;RK_(i->T)) which is then sent to A. (3) Phase-2: Aadaptively issues queries as in Phase-1, and C answers them as beforewith the following restrictions: (i). A cannot issue CorruptedKeyGen(U_(T)) query. (ii) A cannot issue Re-Decrypt(D*; PK_(T)) query.(4) Guess: Finally, A outputs a guess δ′ ϵ{0; 1} and wins the game ifδ′=δ.

Self-Encrypt scheme is a special kind of encryption primitive thatallows a user to store file securely in cloud or any distributedstorage. In this approach the owner of the file uses his/her private keyto encrypt the file. This significantly reduces the computation involvedin storing the file. We provide the self encryption scheme and the proveits CCA security in the random oracle model.

The SE scheme consist of the following algorithms: (1) Setup(K): Let Gbe an additive cyclic group of prime order q. Let P be a generator ofgroup G. Let Δ=Sym.Encrypt, Sym.Decrypt be any symmetric key encryptionscheme. We may assume that A is a symmetric key encryption algorithmthat uses messages of block size k. Choose the hash functions,

H ₁:{0,1}^(l) ^(t) ×Z _(q) *→Z _(q)

H ₂ : Z _(q)*→{0,1}^(l) ^(x)

H ₃: {0,1}^(l) ^(m) ×G→{0,1}^(l) ³

Here l_(t) is the size of the tag, l_(m), is the size of the message andl_(k) is the size of the symmetric key used by the symmetric keyencryption scheme Δ. Also, l₃ is dependent on the security parameter κ.Output Params=(q; G; P; H₁( ); H₂( ); H₃( ), Δ). KeyGen(U, Params): TheKeyGen algorithm generates the public and private key of the user U byperforming the following steps: (i) Choose a random integer x

Z_(q)* (ii) Output PK={X=Xp} and SK=<x>. Self-Encrypt(m, t_(w), SK, PK,Params): On input of message m, tag t_(w), private key SK=x of user U,public key PK=xP of user U and the public parameters Params thisalgorithm will generate the self encryption as follows:

• Choose random t ∈ 

 _(q)* • Set h_(t) = H₁(t_(w), x). • Set C₁ = t + h_(t). • Compute Key =H₂(t) • C2 = {Ĉ_(i)}_((for i=1 to l)) and Ĉ_(i)=Sym.Encrypt (M_(i),Key)for all i = 1 to l, l is  the number of blocks. Assume that m = M₁ M₂... M_(l) where |M_(i)|=k  and k is the block size of Δ. • C₃ = H₃(m, t)• Output the ciphertext C = 

 C₁, C₂, C₃, t_(w) 

 .

Self-Decrypt(C, SK_(i), Params): Self decryption algorithm is used todecrypt the files that are previously encrypted by the user U usinghis/her private key. This algorithm does the following:

  • h_(t) = H₁(t_(w), SK_(i)). • t = C₁ − h_(t) • Key = H2(t) • ComputerM_(i)=Sym.Decrypt(Ĉ_(i), Key) for all i=1 to l and  construct m = M₁ M₂... M_(l). • If C₃ 

 H₃(m, t) then, output m. Else, Output ⊥.

Correctness  of  t: $\begin{matrix}{{RHS} = {C_{1} - h_{t}}} \\{= {\left( {t + h_{t}} \right) - h_{t}}} \\{{= t};} \\{= {LHS}}\end{matrix}$

The Security Proof can be given as follows:

  Theroem 1. If there exist a (γ, ϵ) adversary  

 with an advantage ϵ that can break theIND-SE-CCA security of the SEscheme, then 

 can solve the discrete log problem with advantage ϵ′ where, ϵ′ ≥ ϵ

Proof: In this section we formally prove the security of SE scheme inthe random oracle model. The IND-SE-CCA security of the SE scheme isreduced to the discrete logarithm problem(DLP). The challenger A isgiven with the instance of DLP (i.e. given (q, P, Y) such that q is alarge prime, P, YϵG, find a such that Y=ap.) If there exist an adversaryA that can break the IND-SE-CCA security of the SE scheme, then C canmake use of A to solve the discrete logarithm problem, which is assumedto be hard. Thus the existence of such adversary is not possible.

The challenger C sets the public key PK=Y (PK=aP) and the correspondingprivate key SK=x=a (which is not know to C). C then provides PK to A. Athen has access to various algorithms of SE and the hash functions asoracles. C simulates the hash functions and the Self-Encrypt,Self-Decrypt algorithms as described below.

Phase-1 : 

 is given to access all the oracles as defined in the security modelIND-SE-CCA. Here it should be noted that 

 which does not have the knowledge of private key SK = α provides thefunctionalities Self-Encrypt, Self-Decrypt algorithm.  • The hashfunctions involved in the SE scheme are simulated as random oracles. To  provide consistent output, 

 maintains the lists L_(H) ₁ , L_(H) ₂ , and L_(H) ₃ corresponding to  the hash function H₁, H₂, and H₃ involved in the SE scheme.    * H₁Oracle: When a query with input (t_(w), x) is made, the tuple (t_(w), x,h_(t)) is      retrieved from L_(H) ₁ and h_(t) is returned, if (t_(w),x) is already there in L_(H) ₁ list.      Otherwise, 

 does the following:      • If xP = Y, then abort. This is because 

 obtains the solution to DLP i.e x = α.      • Pick h_(t) ∈ 

 .      • If h_(t) is already present in L_(H) ₁ list, go to previousstep.      • Store (t_(w), x, h_(t)) in L_(H) ₁ list and output h_(t).   * H₂ Oracle: When a query with t is made, 

 the tuple (t, Key) from LH₂ list is      retrieved and will return Key,if (t) is already present in L_(H) ₂ list. Otherwise, 

     does the following:      • Pick Key ∈ {0,1}^(l) ^(k) .      • IfKey is already present in L_(H) ₂ list, go to previous step.      •Store (t, Key) in L_(H) ₂ list and return Key.    * H₃ Oracle: When aquery with input (m, T) is made, 

 retrieves the tuple (m, T, α)      from L_(H) ₃ list and returns α, if(m, T) is already present in L_(H) ₃ list. Otherwise, 

     does the following;      • Pick α ∈ {0,1}^(l) ³ ,      • If α isalready present in L_(H) ₃ list, go to previous step.      •Store 

 m, T, α 

 in L_(H) ₃ list and return α.

The Self-Encrypt and Self-Decrypt as well as Challenge Phase, Phase-2and Guess, according to one embodiment, can be described as follows:

Self-Encrypt Oracle : When a Self-Encrypt query is made with (m, t_(w))as input, 

  does the following:  * Choose random t ∈ 

 _(q)*  * Set h_(t) = H₁(t_(w), x).  * Set C₁ = t + h_(t).  * ComputeKey =H₂(t)  * C₂ = {Ĉ_(i)}_((for i=1 to l)) and Ĉ_(i)=Sym.Encrypt(M_(i), Key) for all i = 1 to l, l is the    number of blocks. Assumethe m = M₁ M₂ ... M_(i) where |M_(i)| = k and k is the    block size ofΔ.  * C₃ = H₃(m, t)  * Output the ciphertext C = 

 C₁, C₂, C₃, t_(w) 

 .  * Output the self-encrypted ciphertext C to 

 . Self-Decrypt Oracle: When a Self-Decrypt query is made with C = 

 C₁, C₂, C₃, t_(w) 

  as input, 

 performs the following:  * If C is its L_(Encrypt) list, pick mcorresponding to C from the tuple 

 C, m 

 in    L_(Encrypt) list and output m.  * If (t_(w), —) is present inL_(H) ₁ list then, retrieve h_(t) corresponding to (t_(w), —) from   L_(H) ₁ list. Else, it returns ⊥  * T = C₁ − ht  * Key = H₂(t)  *Compute M_(i)= Sym.Decrypt(Ĉ_(i), Key) for all i=1 to l and construct m= M₁, M₂ ... M_(l).  * If C₃ 

 H₃(m, t) then, output m. Else, it output ⊥. Challenge Phase: After thefirst phase of training is over. 

 provides m₀, m₁ ∈ 

 , t_(w)* such that (m ₀ , t _(w) *) or (m ₁ , t _(w) *) was not queriedto Self-Encrypt oracle during Phase-1 and provides to 

 , 

 now generates the challenge ciphertext C* = Self-Encrypt(m_(δ), t_(w)*)and δ ∈_(R) {0,1} Phase-2: 

 can interact with all the oracles as in Phase-1 but with the followingrestrictions.  • 

 cannot make the query Self-Decrypt(C*)  • 

 cannot make the query Self-Encrypt(m_(δ), t_(w)*), δ ∈ {0,1} Guess :Once Phase-2 is over, 

 output its guess δ′. 

 wins the game if δ = δ′.

In one embodiment, the proxy re-encryption with self-encryption schemeis described as follows. The SE scheme is modified such a way that itallows verifiability of ciphertext by proxy during re-encryption withoutknowing the message. It helps in achieving CCA security of SE-PRE. Thisalso helps in avoiding the DDOS attack being launched on Proxy'sservice. The proxy is equipped with a method to identify invalidciphertext so that it will serve its functionality only to valid input.Also. the SE-PRE algorithm can be deployed in a simple and efficientmanner than using the traditional PRE schemes available till date. Inone embodiment, the SE-PRE uses private encryption algorithm.

The setup algorithm is described as follows:

Setup(κ):  • Let 

 be an additive cyclic group of prime order q. Let P be a generator ofgroup  

 .  • Let Δ = 

 Sym.Encrypt, Sym.Decrypt 

 be any symmetric key encryption scheme. We   may assume that Δ is asymmetric encryption algorithm wrking on block size k.  • Choose thehash functions, H₀ : {0,1}^(l) ^(c) → {0,1}^(l) ⁰ H₁ : {0,1}^(l) ^(L) × 

 _(q)* × 

 → 

 _(q)* H₂ : 

 _(q)*→ {0,1}^(l) ^(t) H₃ : {0,1}^(l) ^(m) × 

 _(q)* → {0,1}^(l) ⁰ H₄ : 

 _(q)* ×{0,1}(^(l) ^(n) ^(+l) ^(c) ^(+l) ⁰ ) × 

 → 

 _(q)* H₅ : {0,1}^(l) ^(t) × 

 _(q)* × 

 → {0,1}^(l) ⁰ H₆ : {0,1}^(l) ^(w) × 

 × 

 × 

 → 

 _(q)* H₇ : 

 _(q)* × 

 → 

 _(q)* H₈ : 

 × 

 → {0,1}(^(l) ^(w) ^(+l) ^(y) ) H₉ : {0,1}^(l) ^(u) × 

 _(q)* → 

 _(q)* H_(κ) : {0,1}* →{0,1}^(l) ^(c)  Here l_(t) is the size of thetag, l_(m) is the size of the message, l_(c) is the size of theciphertext, l_(p) is  κ and l_(L) is size of the symmetric key used inthe encryption scheme Δ. Also, l_(w), l_(u), l₀,  l₃ and l₅ aredependent on the security paramerter κ.  Output Params = 

 q, P,G, P, H_(i)( )_((for i=0 to 9)), H_(c)( ), Δ 

The KeyGen and RekeyGen can be described as follows:

  KeyGen(U_(i), Params): The KeyGen algorithm generates the public andprivate key of the use U_(i), by performing the following:  • Choose arandom integer x_(i) 

 

 q*  • Output PK_(i) = 

 X_(i) = x_(i)P) and SK = (x_(i) 

 ,

RekeyGen(SK_(i), PK_(i), PK_(i), c_(w), Params): This algorithmgenerates the re-encryption key required to translate a ciphertext ofuser U_(i) into a ciphertext of user U_(j). This is run by the userU_(i). The ciphertext to be re-encrypted is encrypted under the publickey PK_(i) of user U_(i) and with the condition c_(w), which arespecified by user U_(i). This algorithm works as follows:

  • Choose ω 

 ∈ {0,1}^(t) ^(w) • Compute h_(c) = H₁(Cw, x_(i), X_(i)) ∈ 

 _(q)* • Compute r = H₆(ω, x_(i)X_(j), X_(i), X_(j)) ∈ 

 _(q)* • Compute s = H₇(r, X_(j)) ∈ 

 _(q)* • Compute γ = rX_(j) • Compute the re-encryption key RK_(i→j) =

 R₁, R₂, R₃, R₄, R₅, R₆ 

 where, R₁ = s − h_(c) ∈ 

 _(q)* R₂ = rP ∈ 

R₃ = (ω||X_(i)) ⊕ H8(γ, X_(j)) ∈ {0,1}^(l) ^(w) ^(+l) ^(y) R₄ = H₆(ω, γ,X_(i), X_(j)) ∈ 

 q* R₅ = H₅(t_(w), x_(i), X_(i)) ∈ {0,1}^(l) ^(n) R₆ = H₀(t_(w)) •Output the re-encryption key RK_(i→j) =

 R₁, R₂, R₃, R₄, R₅, R₆ 

Self-Encrypt(m, tw, SKi, PKi, Params): On input of message m, tag tw,private key SKi, public key PKi of user Ui and the public parametersParams

• Choose random ω ∈ 

 _(q)* • Set h_(t) = H₁(t_(w), x_(i), X_(i)) ∈ 

 _(q)* • Compute C₁ = t + h_(t). • Compute Key = H₂(t) • Comute C₂ ={Ĉ₁}_((for i=1 to l)) and Ĉ_(i)=Sym.Encrypt (M_(i),Key)  for all i = 1to l. l is the number of blocks. Assume that m =  M₁ M₂ ... M_(l) where|M_(i)|=k and k is the block size of Δ. • Set C₃ = H₃(m, t) • Find α=H₅(t_(w), x_(i), X_(i)) ∈ {0.1}^(l) ⁵ • C₄ = H₄(C₁, C₂, C₃, α, X) • SetC₃ = H₀(t_(w)) • Output the ciphertext C = 

 C₁, H_(c)(C₂), C₃, C₄, C₅) 

 ,

Re-Encrypt(C, PK_(i), PK_(j), c_(w), RK_(i→j), Params): This algorithmis run by the proxy which is given with the re-encryption key RK_(i→j)by user U_(i). This generates the re-encryption of a ciphertextencrypted under public key PK_(i) of user U_(i) under the conditionc_(w) into a ciphertext encrypted under public key PK_(j) of user U_(j).This algorithm does not perform any complex computation and this greatlyreduces the computational overhead on the entity that performs the roleof a proxy. This algorithm does the following computations

  • If C₄ ≠ H₄(C₁, H_(c)(C₂), C₃, R₅, t_(w), X) OR C₅ ≠ R₆, then itreturns ⊥ • Set D₂ = C₂, D₃ = C₃, D₄ = R₂, D₅ = R₃ • Choose u ∈{0,1}^(l) ^(u) • Compute β =H₉(u, R₄) ∈ 

 _(q)* • Compute D1 = β(C₁ + R₁) ∈ 

 _(q)* • Set D₆ = u • Output the re-encrypted ciphertext D = 

 D₁, D₂, D₃, D₄, D₅, D₆ 

Self-Decrypt(C, SK_(i), Params): Self-Decrypt algorithm is used todecrypt the self-encrypted ciphertext C of a user that is stored by himin the cloud. This algorithm performs the following:

  • Find α = H₅(t_(w), x_(i), X_(i)) ∈ {0,1} ^(l) ³ • If C₄ ≠ H₄(C₁, C₂,C₃, α, t_(w), X), then it returns ⊥ • h_(t) = H₁(t_(w), SK_(i)). • t =C₁ − h_(t) • Key = H ₂ (t) • Compute M₁=Sym.Decrypt(Ĉ₁,Key) for all i=1to l and construct m = M₁ M₂ ... M_(l). • If C₃ 

 H₃(m, t) then, output m. Else, Output ⊥.

Correctness  of  t: $\begin{matrix}{{RHS} = {C_{1} - h_{t}}} \\{= {\left( {t + h_{t}} \right) - h_{t}}} \\{= t} \\{= {LHS}}\end{matrix}$

Re-Decrypt(D, SK_(j), Params): The Re-Decrypt algorithm is used todecrypt the re-encrypted ciphertext D. This algorithm does thefollowing:

  • Compute γ =x_(j)D₄ • Compute ω||X_(i) = D₅ ⊕ H₈(γ, X_(j)) • Computer = H₆(ω, x_(j)X_(i), X_(i), X_(j)) ∈ 

 _(q)* • Compute s = H₇(r, X_(j)) ∈ 

 _(q)* • ρ =H₆(ω, γ, X_(i), X_(j)) ∈ 

 _(q)* • Compute β = H₉(D₆, ρ) ∈ 

 _(q)* • Compute t = β⁻¹ (D₁) − s • Find Key = H₂(t) • ComputeM_(i)=Sym.Decrypt(Ĉ_(i), Key) for all i=1 to l and construct m = M₁, M₂... M_(l), • If (C₃ 

 H₃(m, t)) then, output m. Else, it returns ⊥.

A similar Correctness algorithm can be applied, in one embodiment, forexample, as described below:

Correctness  of  T: $\begin{matrix}{{RHS} = {{\beta^{- 1}D_{1}} - s}} \\{= {{\beta^{- 1}\left\lbrack {\beta \left( {C_{1} + R_{1}} \right)} \right\rbrack} - s}} \\{{= {\left\lbrack {\left( {t + h_{t}} \right) + \left( {s - h_{c}} \right)} \right\rbrack - s}};{{{Here}\mspace{14mu} h_{t}} = h_{c}}} \\{= {\left( {t + s} \right) - s}} \\{= t} \\{= {LHS}}\end{matrix}$

The Security Proof of the SE-PRE model can be given as below. Theoriginal ciphertext and the transformed ciphertext security in therandom oracle model are consistent.

Security of the Original Ciphertext

Theorem 2: if a (γ, ϵ) adversary

 with an advantange ϵ breaks the IND- SE-PRE-CCA_(O) security of theSE-PRE scheme in time γ, then

 can solve the discrete log problem or CDH with advantage ϵ′ where,$\epsilon^{\prime} \geq {\frac{1}{q_{t}}\epsilon}$ Here, q_(t) is thenumber of queries to H 

 oracle.

indicates data missing or illegible when filed

Proof: We formally prove the original ciphertext securityIND-SE-PRE-CCA_(O) of SE-PRE scheme in the random oracle model. TheIND-SE-PRE-CCA_(O) security of the SE-PRE scheme is reduced to thediscrete algorithm problem(DLP) or the Computational Diffie HellmanProblem(CDH). The challenger is given with the instance of CDH q, P,Y=aP, Y^(|)=a²p, Z=bP) such that q is a large prime, P, Y, Y′, Z E G.Now, we show that if there exists an adversary A that can breakIND-SE-PRE-CCA₀ security of the SE-PRE scheme then C can make use ofthat adversary A to solve the discrete logarithm problem or the CDHproblem, which are assumed to be hard. Hence the existence of such anadversary A is not possible. Now, adversary A is provided the access tovarious Self-Encrypt, Self-Decrypt, ReKey, Re-Encrypt, Re-Decryptalgorithms and the hash function as oracles. C provides PK_(T)=Y ANDt_(w)* to A. The game is demonstrated below.

Phase-1: 

 interacts with 

 adhering to the restrictions given in the security model IND-SK-PRE-CCA_(O). 

 submits the target condition t_(w)* to 

 . 

 answers the queries made to various Corrupted KeyGen, UncorruptedKeygen, Self-Encrypt, Self-Decrypt,ReKey, Re-Encrypt, Re-Decrypt oraclesand the hash oracles as given below:  • The hash functions are modelledas random oracles. In order to provide consistent out-   put, 

 maintains various lists L_(H) _(κ) and L_(H) ₄ (for i = 0 to 9)corresponding to the hash   function H₀ and H₁, (for i = 0 to 9).Oracles H₁, H₂ and H₃ are simulated as given in   the proof of SEscheme. The other hash oracles are simulated as follows;    * H₀ Oracle:On input of t_(w), 

 checks whether a tuple 

 t_(w), h₈ 

 corresponding to t_(w)     is there in L_(H) ₀ list. If it is alreadypresent then return h₈, else pick h₈ ∈ {0,1}^(l) ⁰ .     Store 

 t_(w), h₀ 

 in L_(H) ₀ list and return h₀.    * H_(c) Oracle: On input of C, 

 checks whether a tuple 

 C, h_(c) 

 corresponding to C is     already there in L_(H) _(c) list. If it ispresent then hc is returned, else pick h_(c) ∈ {0,1}^(l) ^(c) .    Store (C, h_(c)) in L_(H) _(c) list and return h_(c).    * H₁Oracle: When a query with input (t_(w), x, X) is made, the tuple 

 t_(w), x, X ht 

    is retrieved from L_(H) _(t) and h_(t) is returned, if (t_(w), x, X)is already there in L_(H) ₁ list.     Otherwise, 

 does the following:      • If X = X_(t) in L_(Honest) and x _(t)Y = X,then abort. This is because 

 obtains       the solution to DLP i.e x _(t) ⁻¹x = a.      • Pick h_(t)∈ 

 .      • If h_(t) is already present in L_(H) ₁ list, go to previousstep.      • Store (t_(w), x, X, h_(t)) in L_(H) _(t) list and outputh_(t).    * H₄ Oracle: When H₄ oracle is queried with (C₁, C₂, C₃, α,t_(w)) as input, 

    retrieves the tuple (C₁, C₂, C₃, C₄, t_(w), h₄) from L_(H) ₄ listand returns h₄, if an entry     corresponding to (C₁, C₂, C₃, α, t_(w))is already there in L_(H) ₄ list. Otherwise, 

    does the following;      • Pick h₄ ∈ 

 _(q)*.      • If h₄ is already present in L_(H) ₄ list, go to previousstep.      •Store (C₁, C₂, c₃, α, t_(w), h₄) in L_(H) ₄ list and returnh₄.    * H₅ Oracle: When H₅ oracle is queried with (t_(w), x, X) asinput, 

 retrieves the     tuple (t_(w), x, X, h₅) from L_(H) ₅ list and returnsβ, if an entry corresponding to     (t_(w), x, X) is already there inL_(H) ₅ list. Otherwise, 

 does the following:      • Pick h₅ ∈ 

 _(q)*.      • If h₅ is already present in L_(H) ₅ list, go to previousstep,      • Store (t_(w), x, X, h₅) in L_(H) ₅ list and return h₅.    *H₆ Oracle: When H₆ oracle is queried with (ω, γ, X, Y) as input, 

 retrieves the     tuple 

 ω, γ, X, Y, h₆ 

 from L_(H) ₆ list and returns h₆, if an entry corresponding to     (ω,γ, X) is there in L_(H) ₆ list. Otherwise, 

 does the following:      • Pick h₆ ∈ 

 _(q)*.      • If h₆ is already present in L_(H) ₆ list, go to previousstep.      • Store (ω, γ, X, Y, h₆) in L_(H) ₆ list and return h₆.

In one embodiment, H₇ Oracle, Hs Oracle, H₉ Oracle can be described, forexample, as below. A person of ordinary skill in the art wouldunderstand the results are consistent.

    H₇ Oracle: When H₇ oracle is qureried with (r, X) as input, 

 retrieves the tuple     (r, X, h₇) from L_(H) ₇ list and returns h₇, ifan entry corresponding to (r, X) is     already there in L_(H) ₇ list.Otherwise, 

 does the following;      • Pick h₇ ∈ 

 _(q)*.      • If h₇ is already present in L_(H) ₇ list, go to previousstep.      • Store (r, X, h₇) in L_(H) ₇ list and return h₇.     H₈Oracle: When H₈ oracle is queried with (γ, X) as input, 

 retrieves the tuple     

 γ, X, h₈ 

 from L_(H) ₈ list and returns h₈, if an entry corresponding to (γ, X)is     already there in L_(H) ₈ list. Otherwise, 

 does the following:      • Pick h₈ ∈ {0,1}^(l) ^(w) ^(+l) ^(p) .      •If h₈ is already present in L_(H) ₈ list, go to previous step.      •Store (γ, X, h₈) in L_(H) ₈ list and return h₈.     H₉ Oracle: When H₉oracle is queried with (u, r) as input, 

 retrieves the tuple     

 u, r, h₉ 

 from L_(H) ₉ list and returns h₉, if an entry corresponding to (u, r)is     already there in L_(H) ₉ list. Otherwise, 

 does the following:      • Pick h₉ ∈ 

 _(q)*.      • If h₉ is already present in L_(H) ₉ list, go to previousstep.      • Store (u, r, h₉) in L_(H) ₉ list and return h₉. • CorruptedKeygen Oracle : When a query is made with input U_(i), the 

 performs the  following:   * Picks a random x_(i) ∈ 

 _(q)*.   * Computes X_(i) = x_(i)P   * Sets PK_(i) = 

 X_(i) 

 and SK_(i) = 

 x_(i) 

 .   * Stores 

 U_(i), x_(i), X_(i) 

 in L_(Corrupt) list and returns (SK_(i), PK_(i)). Here 

 knows the    private key SK_(i) of user U_(i). • Uncorrupted KeygenOracle :When a query is made with input U_(i), the 

 performs the  following;   * Picks a random x _(i) ∈ 

 _(q)*.   * Computes X_(i) = x _(i)Y = x _(i)aP = x_(i)P, where x_(i) =x _(i)a   * Sets PK_(i) = 

 X_(i) 

 . By definition SK_(i) = 

 x_(i) = x _(i)a 

 . This is not known to  

 ; a is    the discrete log corresponding to Y in the DLP which is givenas the challenge to    

 .   * Stores  

 U_(i), —, x _(i), X_(i) 

 in L_(Honest) list and returns PK_(i).

RekeyGen Oracle, in one embodiment, can be described as follows. Oninput of (c_(w), PK_(i), PKj), C does the following to generate there-encryption key.

 * If (PK_(i) ∈ L_(Corrupt) )    • Compute RK_(i→j) = RekeyGen(c_(w),SK_(i), PK_(i), PK_(j)).    • Store 

 t_(w),PK_(i), PK_(j),RK_(i→j )

 in L_(ReKey) list.    • Output RK_(i→j)  * If t_(w), PK_(i), PK_(j) hasan entry in L_(ReKey) list, retrieve and return RK_(i→j)  * If (PK_(i) ∈L_(Honest) then    • Choose ω 

 ∈ {0,1}^(l) ^(ω)    • Choose h_(c) in ∈ 

 _(q)* and store 

 c_(w), ...., X_(i) 

 in L_(H) ₁ list.    • If X_(j) is corrupt r = H₆(ω, x _(i)x_(j)aP,X_(i), X_(j)) ∈ 

 _(q)*    • If t_(w) = t_(w)* and PK_(i) = PK_(T) then set rb = H₆(ω, x_(i)a²P, X_(i), X_(j)) ∈ 

 _(q)* (Here    

 does not know rb)    • Compute s = H₇(—, X_(j)) ∈ 

 _(q)*    • By definition γ = rX_(j) = rx _(j)abP    • Compute there-encryption key RK_(i→j) = 

 R₁, R₂, R₃, R₄, R₅, R₆ 

 where,        R₁ = s − h_(c) ∈ 

 _(q)*        R₂ = rbP ∈ 

       R₃ = (ω||X_(i)) ⊕ H₈(—, X_(j)) ∈ {0,1}^(l) ^(w) ^(+l) ^(y)       R ⁴ = H ⁶ (ω, —, X ^(i) , X ^(j) ) ∈ 

 _(q)*        R₅ = h₅ ∈ {0,1}^(l) ⁵ , Store(t_(w), —, X_(i), h₅)inL_(H)₅ list        R₆ = H₀(t_(w))    • Output the re-encryption key RK_(i→j)= 

 R₁, R₂, R₃, R₄, R₅, R₆ 

 • Self-Encrypt Oracle : On input of (m, t_(w), PK_(i)), 

 does the following:   * if PK_(i) corrupt, then run Self-Encrypt(m,t_(w), SK_(i), PK_(i))   * If PK_(i) is honest, then perform thefollowing     • Choose random t ∈ 

 _(q)*     • Choose h_(t) ∈ 

 _(q)* and store 

 t_(w), —, X_(i), h_(t) 

 in L_(H) ₁ list.     • Compute C₁ = t + h_(t).     • Compute Key =H₂(t)     • Compute C₂ = {Ĉ_(i)}_((for1=1) _(to l)) andĈ_(i)=Sym.Encrypt (M_(i), Key) for all i = 1       to l, l is the numberof blocks. Assume that m = M₁ M₂ ... M_(l) where |M_(i)|=k       and kis the block of size Δ     • Set C₃ = H₃(m, t)     • Choose α ∈{0,1}^(l) ⁵ and store 

 t_(w), x_(i), X_(i), h₅ = α 

 in L_(H) ₅ list.     • C₄ = H₄(C₁, C₂, C₃, α, X)     • Set C₅ =H₈(t_(w))     • Store (C, t_(w), PK_(i)) in L_(Encrypt) list.     •Output the ciphertext C = 

 C₁, H_(c)(C₂), C₃, C₄, C₅) 

 .  Re-Encrypt Oracle : On input C = 

 C₁, C₂, C₃, C₄, C₅, PK_(i), PK_(j) 

 , 

 does the  following:   * Generate the re-encryption key RK_(i→j) =ReKey(PK_(i), PK_(j))   * Run D = Re-Encrypt(C, RK_(i→j), PK_(i),PK_(j)) as per the algorithm.   * Store 

 C, D, PK_(i), PK_(j), t_(w) 

 in L_(Re-Encrypt) list and output D   Self-Decrypt Oracle: On input 

 C₁, C₂, C₃, C₄, C₅, t_(w), PK_(i) 

 . 

 does the   following:    * If an entry for (C, t_(w), X_(i)) is therein L_(Encrypt) list, return the corresponding m.    * if PK_(i) corrupt,then run Self-Decrypt(C, SK_(i))    * If PK_(i) is honest, then performthe following:     • Find 

 t_(w), x, X, h₅ 

 from L_(H) ₅ list such that (X_(i) = xP) OR (X = X_(i) and x = —).      Set α = h₅. If there is no such entry then query α = H₅(t_(w), —,X_(i)).     • If C₄ ≠ H₄(C₁, C2, C₃, α, t_(w), X), then it returns ⊥Find 

 t_(w), x, X, h₁ 

      from L_(H) _(t) list such that (X_(i) = xP) OR (X = X_(i) AND x =—). Set α = h₅. If       there is no such entry query α = H₅(t_(w), —,X_(i)).     • Find 

 t_(w), x, X, h₁ 

 from L_(H) _(t) list such that (X_(i) = xP) OR (X = X_(i) AND       x =—), then set h_(t) = h₁. If there is no such entry then h_(t) =H₁(t_(w),  , X_(i)).     • t = C₁ − h_(t)     • Key = H₂(t)     •Compute M_(i)=Sym.Decrypt(Ĉ_(i),Key) for all i=1 to l and construct m =M₁       M₂ ... M_(l).     • If C₃ 

 H₃(m, t) then, output m. Else, Output ⊥.  Re-Decrypt Oracle : On inputD = 

 D₁, D₂, D₃, D₄, D₅, t_(w), PK_(j) 

 , 

 does the  following:   * if PK_(j) corrupt, then run Re-Decrypt(D,SK_(j))   * If PK_(i) and PK_(j) are honest, then perform the following   1. Pick γ, h₈, from 

 γ, X, h₈ 

 L_(H) ₈ list for X = X_(j) and    2. For each γ retrieved from L_(H) ₈list: compute ω||X_(i) = D₅ ⊕ h₈ and       r = H₆(ω, x _(j) x _(i)a²P,X_(i), X_(j)). If γ = rX_(j), then proceed with next step, else continue      checking with other γ retrienced from L_(H) ₈ list. If no such γis found, then it       returns ⊥.    3. Compute s = H₇(r, X_(j)) ∈ 

 _(q)*    4. ρ = H₆(ω, γ, X_(i), X_(j)) ∈ 

 _(q)*    5. Compute β = H₉(D₆, ρ) ∈ 

 _(q)*    6. Compute t = β⁻¹(D₁) − s    7. Find Key = H₂(t)    8.Compute M_(i)=Sym.Decrypt(Ĉ₁, Key) for all i=1 to l and construct M₁      M₂ ... M_(l).    9. If (C₃ = 

 H₃(m,t) then, output m. Else, it returns ⊥. Challenge Phase : Once thetraining is over, 

 provides m₀, m₁ ∈ 

 such that (m₀, tw*) or (m₁, t_(w)*) was not queried to Self-Encryptoracle during Phase-1 and provides to 

 . 

generates the challenge ciphertext C* = Self-Encrypt(m_(δ), t_(w)*) andδ ∈_(R) {0,1}

Phase-2 and Guess algorithms, can be described as follows, for example,in one embodiment.

Phase-2:

 can interact with the oracles provided in Phase-1 with the followingrestrictions,  

 cannot make the query Self-Decrypt(C*)  

 cannot make the query Self-Encrypt(m 

, t_(w)*), δ ∈ {0, 1}  

 cannot make the query Re-Encrypt(C*, PK_(T), PK_(j)), PK_(j) ∈L_(Corrupt)  

 cannot make the query Re-Decrypt(D, PK_(j)), if D = Re-Encrypt(C*,PK_(T), PK_(j))  and PK_(j) ∈ L 

   

 cannot make the query ReKey(t_(w)*, PK_(T), PK_(j)) and PK_(j) ∈L_(Corrupt) Guess: After getting sufficient training,  

 output the guess δ′.  

 wins the game is δ = δ′.

 now picks randomly γ from L_(H) _(s) list and provides as solution tothe CDH problem. Security of the Transformed Ciphertext Theorem 3. If a(t, ϵ) adversary

 with an advantange ϵ breaks the IND-SE-PRE-CCA_(T) security of theSE-PRE scheme, then

 can be solve the Computational Diffie Hellman(CDH) problem withadvantage ϵ′ where, $\epsilon^{\prime} \geq {\frac{1}{q_{t}}\epsilon}$Here, q_(t) is the number of queries to H 

 oracle. Proof.: In this section we formally prove the security of thetransformed ciphertext of SE- PRE scheme in the random oracle model. Thesecurity of the scheme is reduced to the CDH problem. The challenger

 is giving the instance of CDH (i.e given (q, P, aP, bP) such that q isa large prime, P, aP, bP, ∈

 find Y such that Y = abP.) Now, if there exist an adversary who canbreak the IND-SE-PRE-CCA_(T) security of SE-PRE then

 can make use of

 to solve the CDH problem, which is assumed to be hard. Hence such an

 does not exist.  All the oracles are similar to that ofIND-SE-PRE-CCA_(O). The challenge ciphertext issued will be atransformed ciphertext A has much more acces than IND-PRE-CCA_(O):  

 is allowed to access the rekey from PK_(T) to any PK_(j).  

 is allowed to access Self-Decrypt for PK_(T) Challenge: After gettingsufficient training

 provides two messages m₀, m₁ and gives to

.

 generates the ciphertext as.  Generate C* = Self-Encrypt(m 

, t_(w) ^(*), PK_(i)); PK_(i) ∈ L_(Honest)  Generate D* = RE-Encrypt(C*,t_(w) ^(*), PK_(i), PK_(T));  Provides D* to

. In Phase-2,

 is now allowed to access all the oracles except: Re-Decrypt(D*,PK_(T)). The rest of the proof is similar to IND-SE-PRE-CCA_(O).

indicates data missing or illegible when filed

Experimental Analysis provides the implementation results and time takenby various algorithms in SE and SE-PRE scheme. We compare the efficiencyof our CCA secure SE scheme with the traditional CPA secure El-Gamalscheme (Weaker security than CCA) and report the same in FIG. 2Table. 1. Also, we have compared our SE-PRE scheme with the onlynon-pairing unidirectional CCA secure PRE scheme by others available.This is reported in FIG. 2 Table. 2. It is a known fact that pairing isvery expensive than other group operations and hence we are not takingany pairing based schemes into consideration. The implementations aredone on 2.4 GHz Intel Core i7 quad-core processor and the results havebeen reported below. The programming language used is Go language, andthe programming tool is Goland 2018.2. The cryptographic protocols areimplemented using the edwards25519-curve, which is the current standarddeployed in cryptocurrencies for fast performances. From the performancecomparison in FIG. 2 Table 1, we note that our CCA secureself-encryption SE scheme is more efficient than the existing CPA-secureEl-Gamal encryption scheme. Also, from FIG. 2 Table 2, it is evidentthat our self-proxy re-encryption SE-PRE scheme without bilinear pairingis more efficient than the existing pairing-free PRE scheme by others.

From the above results it is evident that our SE encryption scheme ispractical and suitable for cloud based scenarios where the userthemselves store their files. Also, the SE-PRE scheme provides a veryefficient approach to share encrypted files mainly in block-chain.

We have given a self encryption scheme SE based on discrete logarithm(DLP) assumption and then extended it to a Proxy Re-Encryption(SE-PRE)scheme suitable for blockchain and distributed storage. First, weformally prove the CCA security of the SE and then the security ofSE-PRE scheme in the random oracle model. We have also implemented ourSE-PRE scheme using GO language. From the results of our implementation,it is evident that our SE-PRE scheme is much efficient than thetechniques available in literature and industry till date. This makes itmore suitable for distributed applications. A person of ordinary skillin the art would understand that one can design a multi-recipient orbroadcast PRE based on the self encryption approach that will providehigh efficiency gain in decentralized platforms.

FIG. 3 is an exploded view of an intermediary system 120 in FIG. 1according to one embodiment disclosing self-encryption in proxyre-encrypt scheme. Different modules within the intermediary system thatoperate according to the disclosures herein are described. For example,module 370 receives ciphertext from one or more clients. Module 310process the received ciphertext and extracts the sender, i.e. the firstuser. Module 310 further extracts the second user to whom the request issupposed to be re-sent. Module 320 validates that the ciphertextoriginated from first user. If the ciphertext is not validated, it isdiscarded immediately and no further action is taken on that ciphertext.If the ciphertext is not validated, error correcting mechanisms may beemployed to check whether the ciphertext is corrupt because of networkconnection failure or an attack by an intruder. Module 330 re-encryptsthe ciphertext based on the re-encryption key created by first userusing second user's public key. Module 340, outputs the re-encryptedciphertext only if original ciphertext was validated. Module 350provides security against chosen cipher attack and denial of serviceattack. Module 360 as a proxy sends the reencrypted ciphertext to thesecond user.

II. Secure Content Access Audit with Blockchain

We provide a fast finality blockchain with cost effective solution thatallows for independent verifiable audit capability along with providingend to end security for content from authoring to distribution.

FIG. 4 discloses a data workflow 400 for an encrypted file that requiresindependent audit response. For example, encrypted file 430 is put onthe blockchain platform by an authenticated owner 410. In oneembodiment, the owner 410 is authenticated using proof of pastpublic/private key transactions on the blockchain platform. In oneembodiment, the owner 410 is authenticated using split-keys on two ormore owner devices. In one embodiment, the owner 410 is authenticatedusing a combination of single signature on and split-key authenticationtechniques. Different users and clients 420 can access the encryptedfile 430 on an ongoing basis according to security policy parameters setby owner. The security policy parameters for the encrypted file 430 areenforced by an intermediary 450. Another intermediary 440 can provideaudit services for the encrypted file.

FIG. 5 is integration at the server level. The idea here is that the endusers will not have any changes to their workflows. Everything is takencare of at the server level. Whenever a user submits data or reads data,it is automatically recorded on the blockchain by the server. This levelof integration provides tamperproof auditability with accurate timestampinformation. It is assumed that the server is trusted at any givenmoment to submit the right data to the blockchain but will not be ableto alter it later on.

FIG. 6 shows integration at the server and client level. There may becases where even the server can't be trusted. Or the enterprise wantsthe audit data to be provided by the client instead of the server. Inthis case, it is expected that each user has credentials with theblockchain and use those credentials to submit their read/writetransactions and then present that as a proof to the server to accessthe content. The server can continue to enforce access control and evenrecord any access that is not permitted presenting the transactionpresented by the user to read the content.

In one embodiment, there is integration at the storage level forenterprises. There are cases where the enterprise prefers to have azero-knowledge storage system. In this model, the storage of the data isdone in a decentralized manner by storage providers and each has accessto only a partial content that is also further secured via encryption.The end user controls the keys to the content and distribute it to usersof their choice via proxy re-encryption keys.

FIG. 7 is a schematic diagram of computing device 700 that can be usedto implement the methods and systems disclosed herein, according to oneor more embodiments. FIG. 7 is a schematic of a computing device 700that can be used to perform and/or implement any of the embodimentsdisclosed herein. In one or more embodiments, client system 110, anintermediary system 120, service provider system 130 of FIG. 1 may bethe computing device 700.

The computing device 700 may represent various forms of digitalcomputers, such as laptops, desktops, workstations, personal digitalassistants, servers, blade servers, mainframes, and/or other appropriatecomputers. The computing device 700 may represent various forms ofmobile devices, such as smartphones, camera phones, personal digitalassistants, cellular telephones, and other similar mobile devices. Thecomponents shown here, their connections, couples, and relationships,and their functions, are meant to be exemplary only, and are not meantto limit the embodiments described and/or claimed.

FIG. 7 shows an example of a computing device 700 on which techniquesdescribed here can be implemented. The computing device 700 can be aconventional computer system that can be used as a client computersystem, such as a wireless client or a workstation, or a server computersystem. The computing device 700 includes a computer 705, I/O devices710, and a display device 715. The computer 705 includes a processor720, a communications interface 725, memory 730, display controller 735,non-volatile storage 740, and I/O controller 745. The computer 705 maybe coupled to or include the I/O devices 710 and display device 715.

The computer 705 interfaces to external systems through thecommunications interface 725, which may include a modem or networkinterface. It will be appreciated that the communications interface 725can be considered to be part of the computing device 700 or a part ofthe computer 705. The communications interface 725 can be an analogmodem, integrated services for digital networks (“ISDN”) modem, cablemodem, token ring interface, satellite transmission interface (e.g.“direct personal computer” also known as “direct PC”), or otherinterfaces for coupling a computer system to other computer systems.

The processor 720 may be, for example, a conventional microprocessorsuch as an Intel Pentium microprocessor or Motorola power PCmicroprocessor. The memory 730 is coupled to the processor 720 by a bus750. The memory 730 can be Dynamic Random Access Memory (DRAM) and canalso include Static RAM (SRAM). The bus 750 couples the processor 720 tothe memory 730, also to the non-volatile storage 740, to the displaycontroller 735, and to the I/O controller 745.

The I/O devices 710 can include a keyboard, disk drives, printers, ascanner, and other input and output devices, including a mouse or otherpointing device. The display controller 735 may control in theconventional manner a display on the display device 715, which can be,for example, a cathode ray tube (CRT) or liquid crystal display (LCD).The display controller 735 and the I/O controller 745 can be implementedwith conventional well-known technology.

The non-volatile storage 740 is often a magnetic hard disk, an opticaldisk, or another form of storage for large amounts of data. Some of thisdata is often written, by a direct memory access process, into memory730 during execution of software in the computer 705. One of skill inthe art will immediately recognize that the terms “machine-readablemedium” or “computer-readable medium” includes any type of storagedevice that is accessible by the processor 720 and also encompasses acarrier wave that encodes a data signal.

The computing device 700 is one example of many possible computersystems that have different architectures. For example, personalcomputers based on an Intel microprocessor often have multiple buses,one of which can be an I/O bus for the peripherals and one that directlyconnects the processor 720 and the memory 730 (often referred to as amemory bus). The buses are connected together through bridge componentsthat perform any necessary translation due to differing bus protocols.

Network computers are another type of computer system that can be usedin conjunction with the teachings described here. Network computers donot usually include a hard disk or other mass storage, and theexecutable programs are loaded from a network connection into the memory730 for execution by the processor 720. A Web TV system, which is knownin the art, is also considered to be a computer system, but it may lacksome of the components shown in FIG. 7, such as certain input or outputdevices. A typical computer system will usually include at least aprocessor, memory, and a bus coupling the memory to the processor.

Though FIG. 7 shows an example of the computing device 700, it is notedthat the term “computer system,” as used here, is intended to beconstrued broadly. In general, a computer system will include aprocessor, memory, non-volatile storage, and an interface. A typicalcomputer system will usually include at least a processor, memory, and adevice (e.g., a bus) coupling the memory to the processor. The processorcan be, for example, a general-purpose central processing unit (CPU),such as a microprocessor, or a special-purpose processor, such as amicrocontroller. An example of a computer system is shown in FIG. 7.

The memory can include, by way of example but not limitation, randomaccess memory (RAM), such as dynamic RAM (DRAM) and static RAM (SRAM).The memory can be local, remote, or distributed. As used here, the term“computer-readable storage medium” is intended to include only physicalmedia, such as memory. As used here, a computer-readable medium isintended to include all mediums that are statutory (e.g., in the UnitedStates, under 35 U.S.C. 101), and to specifically exclude all mediumsthat are non-statutory in nature to the extent that the exclusion isnecessary for a claim that includes the computer-readable medium to bevalid. Known statutory computer-readable mediums include hardware (e.g.,registers, random access memory (RAM), non-volatile (NV) storage, toname a few), but may or may not be limited to hardware.

The bus can also couple the processor to the non-volatile storage. Thenon-volatile storage is often a magnetic floppy or hard disk, amagnetic-optical disk, an optical disk, a read-only memory (ROM), suchas a CD-ROM, EPROM, or EEPROM, a magnetic or optical card, or anotherform of storage for large amounts of data. Some of this data is oftenwritten, by a direct memory access process, into memory during executionof software on the computer system. The non-volatile storage can belocal, remote, or distributed. The non-volatile storage is optionalbecause systems can be created with all applicable data available inmemory.

Software is typically stored in the non-volatile storage. Indeed, forlarge programs, it may not even be possible to store the entire programin the memory. Nevertheless, it should be understood that for softwareto run, if necessary, it is moved to a computer-readable locationappropriate for processing, and for illustrative purposes, that locationis referred to as the memory here. Even when software is moved to thememory for execution, the processor will typically make use of hardwareregisters to store values associated with the software, and local cachethat, ideally, serves to speed up execution. As used here, a softwareprogram is assumed to be stored at an applicable known or convenientlocation (from non-volatile storage to hardware registers) when thesoftware program is referred to as “implemented in a computer-readablestorage medium.” A processor is considered to be “configured to executea program” when at least one value associated with the program is storedin a register readable by the processor.

In one example of operation, a computer system can be controlled byoperating system software, which is a software program that includes afile management system, such as a disk operating system. One example ofoperating system software with associated file management systemsoftware is the family of operating systems known as Windows® fromMicrosoft Corporation of Redmond, Wash., and their associated filemanagement systems. Another example of operating system software withits associated file management system software is the Linux operatingsystem and its associated file management system. The file managementsystem is typically stored in the non-volatile storage and causes theprocessor to execute the various acts required by the operating systemto input and output data and to store data in the memory, includingstoring files on the non-volatile storage.

The bus can also couple the processor to the interface. The interfacecan include one or more input and/or output (I/O) devices. The I/Odevices can include, by way of example but not limitation, a keyboard, amouse or other pointing device, disk drives, printers, a scanner, andother I/O devices, including a display device. The display device caninclude, by way of example but not limitation, a cathode ray tube (CRT),liquid crystal display (LCD), or some other applicable known orconvenient display device. The interface can include one or more of amodem or network interface. It will be appreciated that a modem ornetwork interface can be considered to be part of the computer system.The interface can include an analog modem, isdn modem, cable modem,token ring interface, satellite transmission interface (e.g. “directPC”), or other interfaces for coupling a computer system to othercomputer systems. Interfaces enable computer systems and other devicesto be coupled together in a network.

Several components described here, including clients, servers, andengines, can be compatible with or implemented using a cloud-basedcomputing system. As used here, a cloud-based computing system is asystem that provides computing resources, software, and/or informationto client systems by maintaining centralized services and resources thatthe client systems can access over a communications interface, such as anetwork. The cloud-based computing system can involve a subscription forservices or use a utility pricing model. Users can access the protocolsof the cloud-based computing system through a web browser or othercontainer application located on their client system.

The invention disclosure describes techniques that those of skill in theart can implement in numerous ways. For instance, those of skill in theart can implement the techniques described here using a process, anapparatus, a system, a composition of matter, a computer program productembodied on a computer-readable storage medium, and/or a processor, suchas a processor configured to execute instructions stored on and/orprovided by a memory coupled to the processor. Unless stated otherwise,a component such as a processor or a memory described as beingconfigured to perform a task may be implemented as a general componentthat is configured to perform the task at a given time or a specificcomponent that is manufactured to perform the task. As used here, theterm ‘processor’ refers to one or more devices, circuits, and/orprocessing cores configured to process data, such as computer programinstructions.

A detailed description of one or more implementations of the inventionis provided here along with accompanying figures that illustrate theprinciples of the invention. The invention is described in connectionwith such implementations, but the invention is not limited to anyimplementation. The scope of the invention is limited only by the claimsand the invention encompasses numerous alternatives, modifications andequivalents. Numerous specific details are set forth in the followingdescription in order to provide a thorough understanding of theinvention. These details are provided for the purpose of example and theinvention may be practiced according to the claims without some or allof these specific details. For the purpose of clarity, technicalmaterial that is known in the technical fields related to the inventionhas not been described in detail so that the invention is notunnecessarily obscured.

Some portions of the detailed description are presented in terms ofalgorithms and symbolic representations of operations on data bitswithin a computer memory. These algorithmic descriptions andrepresentations are the means used by those skilled in the dataprocessing arts to most effectively convey the substance of their workto others skilled in the art. An algorithm is here, and generally,conceived to be a self-consistent sequence of operations leading to adesired result. The operations are those requiring physicalmanipulations of physical quantities. Usually, though not necessarily,these quantities take the form of electrical or magnetic signals capableof being stored, transferred, combined, compared, and otherwisemanipulated. It has proven convenient at times, principally for reasonsof common usage, to refer to these signals as bits, values, elements,symbols, characters, terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar termsare to be associated with the appropriate physical quantities and aremerely convenient labels applied to these quantities. Unlessspecifically stated otherwise as apparent from the following discussion,it is appreciated that throughout the description, discussions utilizingterms such as “processing” or “computing” or “calculating” or“determining” or “displaying” or the like, refer to the action andprocesses of a computer system, or similar electronic computing device,that manipulates and transforms data represented as physical(electronic) quantities within the computer system's registers andmemories into other data similarly represented as physical quantitieswithin the computer system memories or registers or other suchinformation storage, transmission or display devices.

Techniques described here relate to apparatus for performing theoperations. The apparatus can be specially constructed for the requiredpurposes, or it can comprise a general-purpose computer selectivelyactivated or reconfigured by a computer program stored in the computer.Such a computer program may be stored in a computer-readable storagemedium, such as, but is not limited to, read-only memories (ROMs),random access memories (RAMS), EPROMs, EEPROMs, magnetic or opticalcards, any type of disk including floppy disks, optical disks, CD-ROMs,and magnetic-optical disks, or any type of media suitable for storingelectronic instructions, and each coupled to a computer system bus.Although the foregoing implementations have been described in somedetail for purposes of clarity of understanding, implementations are notnecessarily limited to the details provided.

III. Multiple Signatures on a Smart Wallet

In one embodiment, a smart wallet is made of Modern Portfolio Theory(MPT) wallet. Users can add T-of-N multi-sig capabilities to standardMPT wallets. Votes to send tokens must arrive one-per-transaction andare stored in public blockchain state. A group signature on adescription of transfer is recovered from the votes. Validation of thesignature happens outside of the smart contract. State may be prunedsafely, allowing amnesiac property of miners is preserved without lossof security.

In one embodiment, a single, shared smart contract collects votes forproposals to send tokens between wallets. In one embodiment, the walletassociated with the smart contract is not used and multiple-signatures(“multi-sig”) are sent directly on standard modern portfolio theory(“MPT”) based wallets. This removes the support for non-token-transferoperations guarded by a multi-sig, meaning in one embodiment, thisdesign will not support data transactions or arbitrary smart contractcalls. The policy of multi-sig is enforced automatically. In oneembodiment, threshold cryptography will be utilized to create signaturesfor the exchange/corporate MPT wallet. In one embodiment, Shamir'ssecret sharing is used as a simple way to create keys capable of thisfeature. New transactions will not be dynamically created inside thesmart contract.

The benefits of implementing multiple signatures on a smart walletinclude creation of multi-signature wallets, voting for transfers andpruning of old proposed transfers and votes. Any implementation has toconsider the following before finalizing transactions on the smartwallet: querying whether multi-signature capabilities already exist;updating the list of signers and/or required number of votes; deletionof multi-signature capabilities for a wallet.

Allow creation of a multiple signature wallet context for a wallet. Thetransaction containing this request must be send from the targetwallet's client. It must include a list of voter public keys and theminimum number of votes that must be collected before funds may be sentfrom the wallet. If a wallet with this multi-sig wallet context alreadyexists, it is an error. Don't disallow normal TxnTypeSend from a walletfor which a multi-sig wallet context exists. Allow creation of multi-sigtransfer votes for a wallet. The votes must contain a proposal ID valueto differentiate between multiple transfers of the same value to thesame client. Different multi-sig wallet contexts may have proposals withthe same ID. When a vote is sent with an ID not currently in thedatabase, a proposal object is created in state. A vote must contain aninner signature produced by the vote's sender. This signature is on amessage similar to the following:

-   -   “${FromWalletID}:${ToWalletID}:${Value}.

Add chaincore/chain/state_context.go # AddSignedTransfer( ) call that issimilar to AddTransfer( ) but which also takes a signature and may sendfrom any wallet. This AddSignedTransfer call reconstructs the messageabove and validates the passed signature against it and from thewallet's public key. If the signature is invalid, the call fails and thetransfer is rejected.

When the required number of votes are collected on a multi-sig sendproposal, it is executed. If the wallet does not have enough balance tocomplete the transaction, the vote transaction succeeds (so as toeligible to be included in a block) but does not count the vote towardthe proposal and a transaction output message that there aren't enoughfunds. Because the vote is not counted, it allows the last voter to tryagain later. If the transfer succeeds, the proposal object that wasallocated for this transfer is not deleted yet. This allows us to telladditional votes that come in soon after that their proposal was alreadyexecuted.

Multi-sig proposals are assigned an expiration date by the smartcontract. When the expiration date is past, a proposal is eligible fordeletion.

When a vote comes in, the blockchain checks the oldest proposal it knowsof (across all multi-sig wallets, not just the one being voted on) tosee if it is expired. If so, it is deleted (“pruned”) and the ID valuethat the proposal held is free to be re-used by the originatingmulti-sig wallet. Only one proposal may be deleted per incoming vote toprotect against any single vote transaction performing a large amount ofIO. This will help to future-proof this multi-sig wallet scheme from anyIO quota policy the blockchain might decide to one day startimplementing.

If a vote comes in for a proposal that is past expiry but which has notbeen pruned yet, the proposal is immediately deleted (“pruned”) and anew proposal with the same ID is instantiated. This presents aconsistent behavior between an expired-deleted and anexpired-not-yet-deleted proposal.

In one embodiment, multiple signature smart wallet is implemented asfollows. First a user needs to do threshold signature setup. As part ofthis setup, the user creates a desired number of t-of-n private/publickeys. Then the user recovers the group private/public key. This groupkey is used to register a group wallet on the blockchain and the tokenbalance is stored against this group client. Whenever the tokens in thisgroup wallet needs to be withdrawn, individual clients submit theirshare of the transaction as a regular blockchain transaction. Theseindividual transactions contains a shared signature for a giventransaction payload which authorizes transfer of certain amount oftokens to a specific client for a given context. When enough suchsignatures (t) are recovered, then the group signature is recovered.This group signature is presented to withdraw the funds. The blockchainfund transfer API doesn't need to be aware of all this additional setup.As far as it is concerned, it is transferring the funds based on asignature of a wallet. This provides a secure multi-sig capability.

In one embodiment, the use of group key and receipt of signatures isimplemented without smart contract voting. The scheme seamlesslyachieves all the functions of a single signature wallet. It can bereplace a single signature wallet without any additional changesrequired to API or blockchain platform environment.

FIG. 8 shows 800 multiple-signature wallet flow for messages betweendifferent entities. At 810 is Administrator of the blockchain, 820 isthe Exchange application for transactions, 830-1,2,3, . . . n aredifferent multiple signers, 840 is the smart contract, 850 is modernportfolio theory wallet, 860 is the depositor and 870 is the withdrawer.The figure shows register, deposit and withdraw events and correspondingmessages according to one embodiment.

FIG. 9 shows 900 multiple-signature wallet flow for messages betweendifferent entities in one embodiment. At 910 is the Administrator, 920is the Exchange application, Signers are at 930-1,2,3, . . . n, 940 isthe shared multiple-signature wallet associated with a smart contract,950 is the modern portfolio theory wallet, 960 is the depositor, and 970is the withdrawer. The figure shows register, deposit and withdrawevents and corresponding messages according to one embodiment.

IV. Split Key Authentication and Password-Less Login

Blockchain platform with a novel split-key1 mechanism is used to providemore secure authentication and password-less login. Interestingly thesame scheme can also be used in an enterprise SSO setting by replacingthe traditional password based login with a more secure authenticationusing only digital keys and just using the laptop/desktop and mobile appand no special hardware.

The value proposition for this approach is a higher security and aneasier password-less login flow, without the need for hardware devices,fingerprint, or face recognition schemes as this approach has a built-inhigher level of security. The latter methods can still be added as anadd-on to further bolster the security of the login process.

Enterprises already use SSO to make it easy for their employees to loginto their various internal application that each require login. Existingsolutions rely on password based authentication. And some requirechanging the password every few weeks or months. Some even preventreusing the previous 10 passwords, making it extremely painful toemployees. While this improves the security, it imposes unnecessaryburden on the employees.

In one embodiment, a novel split key based signature scheme is used thatrequires two separate signatures from two split keys (of the primarykey) to create the combined signature. These partial signatures areconstructed on two separate devices to enhance the security. Compromiseof one key doesn't result in the compromise of the primary key. Thistechnique can be used to provide authentication service to existing SSOservers.

Below is the outline of the first-time registration and subsequent loginprocesses. Registration: 1) User accesses the SSO login page in thebrowser. 2) User is presented with the familiar login form. 3) User doesthe login by entering username and password. 4) At this time, the SSOserver will work with blockchain IDP server and identify the user needsto register into the split key IDP service. 5) Blockchain IDP provides asession ID and a challenge tracking that the SSO server sends to theUser. 6) User's browser redirects and opens a desktop app. 7) Thedesktop app has the ability to connect to a mobile device via a shortrange wireless connection, for example, a bluetooth protocol or nearfield communications protocols. 8) The desktop will sign the challengepartial key and send the signature to the mobile. 9) The mobile willsign the challenge with its own partial key, combine the signatures andrespond back to the blockchain IDP server along with the primary publickey. 10) The blockchain IDP server confirms that the signature is validwith respect to the public key and registers the phone and the publickey against the user. 11) Blockchain IDP server responds to SSO of thesuccessful registration. 12) SSO server redirects the user to theapplication.

Password-less Login: 1) User accesses the SSO login page in the browser.2) User is presented with the familiar login form. In addition, therewill be a link to use the split key based authentication (note that thisextra step of clicking the link can be bypassed if there is a cookieinformation from a prior session that user is already setup for splitkey authentication). 3) SSO server works with blockchain IDP server andprovides a challenge. This will happen either directly as a response tostep 1 or after user explicitly clicks the link to use split keyauthentication in step 2 (that depends on the cookie information). 4)Browser redirects and opens the desktop app. 5) The flow from here issame as the Registration process from step 7.

Note that the desktop app is only required at this time because of thelocal communication with the mobile phone. As Web Bluetooth API becomeswidely adopted, the desktop app can be completely eliminated and thecommunication will happen directly between the browser and the mobilephone.

Also, in the above description, the SSO server and blockchain IDPservice are mentioned as two separate servers. However, it is alsopossible to make blockchain IDP service available as a pluggable moduleinto existing SSO solutions.

FIG. 10 shows the message flow 1000 for split-key authenticationaccording to one embodiment. At 1010 is the user, 1020 is the desktop orfirst device of the user, 1030 is the second device or mobile of theuser, 1040 is the Single-sign on (“SSO”) server, 1050 is the BlockchainIDP Server. The figure shows Register and Login events and correspondingmessage flow according to one embodiment.

FIG. 11 is depicts a flowchart 1100 illustrating an example of a methodfor a blockchain platform to achieve split-key authentication andpasswordless login, according to one embodiment. The flowchart 1100 isdiscussed in conjunction with the blockchain platform environment shownin the diagram 100 in FIG. 1. At block 1105, for a given client login,create a public and private key at a client device. At block 1110, splitthe private key of the client into two or more parts. At block 1115,assign the split private key part to two or more client devices. At1120, signing to authenticate a challenge using a partial key part atone of the client devices. At 1125, send the challenge to the remainingclient devices who sequentially sign using short range wireless networkconnection, for example, Bluetooth protocol or near field communication.At 1130, respond back to the challenge to login without a password. At1135, receive authentication complete based on the response to thechallenge. At 1140, getting access to the application or resources basedon the authentication.

In broad embodiment, the invention is systems and methods of ablockchain platform for intermediaries to provide different servicesincluding proxy re-encryption, independent audit services, multi-sigsmart wallet and split-key based passwordless login.

A number of embodiments have been described. Nevertheless, it will beunderstood that various modifications may be made without departing fromthe spirit and scope of the claimed invention. In addition, the logicflows depicted in the figures do not require the particular order shown,or sequential order, to achieve desirable results. In addition, othersteps may be provided, or steps may be eliminated, from the describedflows, and other components may be added to, or removed from, thedescribed systems. Accordingly, other embodiments are within the scopeof the following claims.

It may be appreciated that the various systems, methods, and apparatusdisclosed herein may be embodied in a machine-readable medium and/or amachine accessible medium compatible with a data processing system(e.g., a computer system), and/or may be performed in any order.

The structures and modules in the figures may be shown as distinct andcommunicating with only a few specific structures and not others. Thestructures may be merged with each other, may perform overlappingfunctions, and may communicate with other structures not shown to beconnected in the figures.

The above-described functions and components may be comprised ofinstructions that are stored on a storage medium such as a computerreadable medium. The instructions may be retrieved and executed by aprocessor. Some examples of instructions are software, program code, andfirmware. Some examples of storage medium are memory devices, tapes,disks, integrated circuits, and servers. The instructions areoperational when executed by the processor to direct the processor tooperate in accord with some embodiments. Those skilled in the art arefamiliar with instructions, processor(s), and storage medium.

While the foregoing written description of the invention enables one ofordinary skill to make and use what is considered presently to be thebest mode thereof, those of ordinary skill will understand andappreciate the existence of variations, combinations, and equivalents ofthe specific embodiment, method, and examples herein. The inventionshould therefore not be limited by the above described embodiment,method, and examples, but by all embodiments and methods within thescope and spirit of the invention.

A detailed description of one or more implementations of the inventionis provided here along with accompanying figures that illustrate theprinciples of the invention. The invention is described in connectionwith such implementations, but the invention is not limited to anyimplementation. The scope of the invention is limited only by the claimsand the invention encompasses numerous alternatives, modifications andequivalents. Numerous specific details are set forth in the followingdescription in order to provide a thorough understanding of theinvention. These details are provided for the purpose of example and theinvention may be practiced according to the claims without some or allof these specific details. For the purpose of clarity, technicalmaterial that is known in the technical fields related to the inventionhas not been described in detail so that the invention is notunnecessarily obscured.

The structures and modules in the figures may be shown as distinct andcommunicating with only a few specific structures and not others. Thestructures may be merged with each other, may perform overlappingfunctions, and may communicate with other structures not shown to beconnected in the figures.

1. A method on a blockchain platform for one or more intermediariescomprising: receiving a ciphertext from a first user with conditionparameters that has been encrypted with a dynamically selectedencryption algorithm; receiving a re-encryption key for a second userfrom the first user; identifying whether the ciphertext is valid;re-encrypting the ciphertext; outputting the re-encrypted ciphertextonly if the ciphertext is valid; and achieving security against chosenciphertext attack and distributed denial-of-service attack; sending there-encrypted ciphertext to the second user for decryption.
 2. The methodof claim 1, wherein the intermediary does not have the ability todecrypt the received ciphertext.
 3. The method of claim 1, furthercomprising: skipping outputting the re-encrypted ciphertext based on oneor more condition parameters.
 4. The method of claim 1, furthercomprising: sending the re-encrypted ciphertext to a second intermediaryfor second hop re-encryption.
 5. A method of a blockchain platform foran intermediary, comprising: receiving an encrypted file from a user forstorage on the blockchain platform; mapping the user to be the owner ofthe encrypted file; receiving one or more security policy parameters forthe encrypted file from the owner; enforcing the security policyparameters for all access requests to the file on the blockchainplatform; and optionally providing audit report of the encrypted filestorage and access.
 6. The method of claim 5, wherein the owner isestablished using past read or write transactions performed directly onthe blockchain platform.
 7. The method of claim 5, further comprising:dividing the encrypted file into two or more parts before sending forstorage on the blockchain platform.
 8. A method of a blockchain platformfor a smart wallet, comprising: assigning a total number of two or morepublic-private key pairs for users associated with the smart wallet;allocating a threshold number for approval on transaction on the smartwallet wherein the threshold number is less than or equal to the totalnumber; creating a group key from the total number of public-privatekeys and the threshold number for approvals; using the group key toregister the smart wallet on the blockchain; receiving for a transactiona shared signature based on the group key from two or more users;validating and finalizing the transaction when the received signaturesare more than the threshold number.
 9. The method of claim 8, wherein:the smart wallet with the group key supports all the functions of asingle user wallet.
 10. A method of blockchain platform forauthenticating clients, comprising of: creating a public and private keyat a client device; splitting the private key into two or more parts;assigning the split private key part to two or more client devices;signing to authenticate a challenge using a partial key part at one ofthe client devices; sending the challenge to the remaining clientdevices who sequentially sign using short range wireless networkconnection; responding back to the challenge to login without apassword.
 11. A system on a blockchain platform for one or moreintermediaries comprising: a module to receive a ciphertext from a firstuser with condition parameters that has been encrypted with adynamically selected encryption algorithm; a module to receive are-encryption key for a second user from the first user; a module toidentify whether the ciphertext is valid; a module to re-encrypt theciphertext; a module to output the re-encrypted ciphertext only if theciphertext is valid; and a module to achieve security against chosenciphertext attack and distributed denial-of-service attack; a module tosend the re-encrypted ciphertext to the second user for decryption. 12.The system of claim 11, wherein the intermediary does not have theability to decrypt the received ciphertext.
 13. The system of claim 11,further comprising: a module to skip outputting the re-encryptedciphertext based on one or more condition parameters.
 14. The system ofclaim 11, further comprising: a module to send the re-encryptedciphertext to a second intermediary for second hop re-encryption.
 15. Asystem of a blockchain platform for an intermediary, comprising: amodule to receive an encrypted file from a user for storage on theblockchain platform; a module to map the user to be the owner of theencrypted file; a module to receive one or more security policyparameters for the encrypted file from the owner; a module to enforcethe security policy parameters for all access requests to the file onthe blockchain platform; and optionally a module to provide audit reportof the encrypted file storage and access.
 16. The system of claim 15,wherein the owner is established using past read or write transactionsperformed directly on the blockchain platform.
 17. The system of claim15, further comprising: a module to divide the encrypted file into twoor more parts before sending for storage on the blockchain platform. 18.A system of a blockchain platform for a smart wallet, comprising: amodule to assign a total number of two or more public-private key pairsfor users associated with the smart wallet; a module to allocate athreshold number for approval on transaction on the smart wallet whereinthe threshold number is less than or equal to the total number; a moduleto create a group key from the total number of public-private keys andthe threshold number for approvals; a module to use the group key toregister the smart wallet on the blockchain; a module to receive for atransaction a shared signature based on the group key from two or moreusers; a module to validate and finalize the transaction when thereceived signatures are more than the threshold number.
 19. The systemof claim 18, wherein: the smart wallet with the group key supports allthe functions of a single user wallet.
 20. A system of blockchainplatform for authenticating clients, comprising of: a module to create apublic and private key at a client device; a module to split the privatekey into two or more parts; a module to assign the split private keypart to two or more client devices; a module to sign to authenticate achallenge using a partial key part at one of the client devices; amodule to send the challenge to the remaining client devices whosequentially sign using short range wireless network connection; amodule to respond back to the challenge to login without a password.